home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000171_misckit-reques…aska.et.byu.edu_Thu Apr 7 03:40:43 1994.msg < prev    next >
Internet Message Format  |  1994-10-30  |  3KB
  1. Return-Path: <misckit-request@alaska.et.byu.edu>
  2. Received: from alaska.et.byu.edu by darth.byu.edu (NX5.67d/NX3.0M)
  3.     id AA12342; Thu, 7 Apr 94 03:40:36 -0600
  4. Received: from nexus.yorku.ca by alaska.et.byu.edu; Thu, 7 Apr 1994 02:10:22 -0600
  5. Received: from monkey.circus.yorku.ca ([130.63.216.22]) by nexus.yorku.ca with SMTP id <9218>; Thu, 7 Apr 1994 04:10:22 -0400
  6. Received: by monkey.circus.yorku.ca (NX5.67e/NX3.0M_DA_Jan30-93)
  7.     id AA03389; Thu, 7 Apr 94 04:07:20 -0400
  8. From: "David Aspinall" <dave@circus.yorku.ca>
  9. Message-Id: <9404070807.AA03389@monkey.circus.yorku.ca>
  10. Subject: Re: MiscKit.pkg
  11. To: misckit@alaska.et.byu.edu
  12. Date:     Thu, 7 Apr 1994 04:07:18 -0400
  13. Mime-Version: 1.0
  14. Content-Type: text/plain; charset=US-ASCII
  15. Content-Transfer-Encoding: 7bit
  16. Content-Length: 1822      
  17.  
  18.  
  19. << section where we thank all the contributors for their work ..  deleted >>
  20. << some really excellent work though ... :) >>
  21.  
  22. My $.02:
  23.  
  24. I like the the idea of a pkg, although to be honest I am one of those
  25. people who would insist on compiling it myself.  I always hold onto the
  26. previous source when I compile a new release just in case there is some
  27. BIG problem with the new release.
  28.  
  29. What I would like is to .. maybe .. split the kit up into logical units.
  30. Rather than one big 50 Mb kit, and one 6Mb debug library, why not
  31. several.  Now I know setting this up could take alot of work so I'm not
  32. really pushing, just suggesting.
  33.  
  34. What I'm thinking of is kinda a hierarchy of dependance.  Sort of like
  35. how you (probably) couldn't use IndexingKit without using the Appkit
  36. (although I haven't tried this).  So we might start with 
  37.  
  38. MiscFoundation
  39.     MiscString and other base level data structures
  40.  
  41. MiscFind
  42.     Its already a partioned project, why not a separate library.
  43.     Dependant on a compiled MiscFoundation library.
  44.  
  45. MiscAppkitExtensions
  46.     Views, buttons, sliders, anything that is directly connected to the
  47. appkit, or maybe MiscInterfaces.  I know the palettes are already
  48. separate libraries, but they could be consolidated.
  49.     Dependant on a compiled MiscFoundation library.
  50.  
  51.  
  52. Anyway, the only reason I see this as having any merit (as an idea) is to
  53. collect sections that are not changing as often, and hold them at one
  54. release.  This way you only have to compile the kit that changes and the
  55. dependent kits.  Even then you don't have to distribute dependent kits if
  56. they haven't changed, the end users simply have to rebuild the
  57. dependancies.
  58.  
  59. Personally I prefer one big kit, a cohesive well thought out whole, but
  60. for those who might be juggling disk space this might help.
  61.  
  62. David
  63.  
  64. (it sounds like a good idea at 4am...)